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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage three Protocol Description of the Conference (CONF) service based on stage 
one and two of the ISDN CONF supplementary service. It provides the protocol details in the IP Multimedia (IM) Core 
Network (CN) subsystem based on the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). 

The present document specifies centralized conferencing, using a conference focus, distributed conferencing is out of 
scope. 

The present document does not cover the cases of : 

a) cascading conference services; and 

b) the support of the PSTN/ISDN conference service hosted in the PSTN. 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the CONF supplementary service. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service 
and supplementary services; Stage 1". 

[2] 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[3] Void 

[4] Void. 

[5] Void. 

[6] Void. 

[7] 3GPP TS 24.147: "Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; 

Stage 3". 

[8] IETF RFC 389 1 : "The SIP Replaces header" . 

[9] Void. 

[10] Void 

[II] 3GPP TS 24.628: "Common Basic Communication procedures using IP Multimedia (IM) Core 
Network (CN) subsystem; Protocol specification". 

[12] 3GPP TS 24.610: "Communication HOLD (HOLD) using IP Multimedia (IM) Core Network 

(CN) subsystem; Protocol specification". 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TS 22.173 [1] and 
3GPPTS 24.147 [7] apply. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ACR/CB Anonymous Communication Rejection and Communication Barring 

AS Application Server 

CDIV Communication Diversion 

CONF CONFerence calling 

CS Circuit Switch 

ECT Explicit Communication Transfer 

HOLD communication HOLD 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

ISDN Integrated Service Data Network 

MCID Malicious Communication IDentification 

MGCF Media Gateway Control Function 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

P-CSCF Proxy CSCF 

PSTN Public Switched Telephone Network 

SIP Session Initiation Protocol 

TIP Terminating Identification Presentation 

TIR Terminating Identification Restriction 

UE User Equipment 



CONFerence (CONF) 



4.1 



Introduction 



The CONFerence (CONF) service enables a user to participate in and control a simultaneous communication involving 
a number of users. 

4.2 Description 
4.2.1 General description 

When the CONF service is invoked, conference resources are allocated to the served user. 

Once a conference is active, users can join and leave a conference, and remote users can be added to or removed from 
the conference. 

Conference participants can request to be informed of these actions. 
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4.3 Operational requirements 

4.3.1 Provision/withdrawal 

The CONF service shall be provided after prior arrangement with the service provider. 

4.3.2 Requirements on the originating network side 

No specific requirements are needed in the network. 

4.3.3 Requirements in tine network 

No specific requirements are needed in the network. 

4.3.4 Requirements on tine terminating network side 

No specific requirements are needed in the network. 

4.4 Coding requirements 

For coding requirements see 3GPP TS 24.147 [7], clause 5. 

4.5 Signalling requirements 

4.5.1 Activation/deactivation 

The CONF service is activated at provisioning and deactivated at withdrawal. 

4.5.1a Registration/erasure 

The CONF service requires no registration. Erasure is not applicable. 

4.5.1b Interrogation 

Interrogation of CONF is not applicable. 

4.5.2 Invocation and operation 

This subclause describes the usage of and the changes to the procedures of 3GPP TS 24. 147 [7] for invoking and 
operating a conference. 

4.5.2.1 Actions at the originating UE 

4.5.2.1 .1 User joining a conference 

Procedures according to 3GPP TS 24.147 [7], subclause 5.3.1.4 shall apply. 

4.5.2.1 .2 User inviting another user to a conference 

Procedures according to 3GPP TS 24.147 [7], subclause 5.3.1.5 shall apply with the following additions to 
subclause 5.3.1.5.3 of 3GPP TS 24.147 [7]: 

In order to avoid the establishment of a second communication to the invited user, in case of an active session 
the UE may additionally include the Replaces header in the header portion of the SIP URI of the Refer-to header 
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of the REFER request. The included Replaces header shall refer to the active dialog that is replaced by the ad- 
hoc conference. The Replaces header shall comply with RFC 3891 [8]. 

NOTE 1 : In case of an interworking to the PSTN the routing of the INVITE request from the conference focus to 
the MGCF that handles the Replaces information is not deterministic and the replacement of the active 
dialog might fail. 

EXAMPLE: Refer-To: <sip:mgcfl. homel.net; method=INVITE?Replaces=cb03a0s09a2sdfglkj490333%3Bto- 

tag%3D 314159%3Bfrom-tag%3D171828&Requrie=replaces >. 

NOTE 2: If a conference participant invites another user to a conference by using a REFER request targeted at the 
other user (following 3GPP TS 24.147 [7] , subclause 5.3.1.5.2), there can be cases where such REFER 
request is intercepted by an AS serving the requesting user which applies special REFER handling 
procedures according to 3GPP TS 24.628 [11] subclause 4.7.2.9.7.2. The consequence of this is that the 
conference focus AS will receive an INVITE from the referrers AS and not from the targeted user. This 
however does not affect the conference focus procedures in any way. 

4.5.2.1 .3 User leaving a conference 

Procedures according to 3GPP TS 24.147 [7], subclause 5.3.1.6 shall apply. 

4.5.2.1 .4 User creating a conference 

Procedures according to 3GPP TS 24.147 [7], subclause 5.3.1.3 shall apply. 

4.5.2.1 .5 Subscription for the conference event package 

Procedures according to 3GPP TS 24.147 [7], subclause 5.3.1.2 shall apply. 

4.5.2.2 Actions at the conferencing AS 

4.5.2.2.1 Conference focus 

Procedures according to 3GPP TS 24.147 [7] , subclauses 5.3.2 and 6.3.2 shall apply with the following additions to 
subclause 5.3.2.5.2 of 3GPP TS 24.147 [7]: 

If a Referred-By header is available in the REFER request, the AS shall verify if the provided Referred-By 
header contains a valid identity of the requesting user. If not, the AS shall replace the Referred-By header with a 
valid value matching the P-Asserted-Identity header in the REFER request. 

If no Referred-By header is available in the request, the AS shall add a Referred-By header that matches the P-Asserted- 
Identity header in the REFER request. 

The procedures described in subclause 5.3.2.5.5 of 3GPP TS 24.147 [7] shall not apply. 

4.5.2.2.1 A AS Procedures with 3PCC 

If 3-Way Calling with 3PCC is applied, the AS serving the controlling UE shall first check that a valid REFER request 
is received on the dialog to be transferred: 

The Request-URI in the REFER request is targeted to the same UE instance (remote UE) that is involved in the 
dialog; and. 

The Refer-To header in the REFER request contains an URI so that the method constructed from the URI is 
equal to an INVITE request to the Conference focus. 

Otherwise, the AS may, depending on the operator policy: 

Reject the REFER request; or. 

Handle the REFER request with another service; or 

Proxy the REFER request on. 
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If the AS determines that the REFER request is valid for 3PCC, the AS shall: 

terminate the REFER request from the controlling UE by sending 202 Accepted response; 

send a NOTIFY request containing the message/sipfrag body of "SIP/2.0 100 Trying"; 

send an INVITE request to the conference server without SDP content body based on the Refer-To header in the 
REFER request; 

Upon receiving a reliable response (reliable 18x response or 200 OK response) from the conference server, due to the 
AS generated INVITE request triggered by a REFER request, the AS shall generate a re-INVITE request to the remote 
UE identified in that REFER request. The re-INVITE shall include the media information in the SDP offer that matches 
what was received from the conference server. The re-INVITE request is sent to the remote UE over the existing dialog. 

Upon receiving a reliable response (200 OK) to the re-INVITE request from the remote UE with SDP answer 
information in the message body, the AS shall include the media information in the SDP answer into the next eligible 
request toward the conference server as an answer to the original SDP offer received. The next eligible request may be 
one of the following: 

PRACK request for a reliable 18x response; or 

ACK request for 200 (OK) response. 

Upon successful completion of the 3PCC procedure between the conference server and the remote UE, the AS shall 
send a NOTIFY request to the controlling UE to indicate that the call transfer has been completed based on the REFER 
request. 

4.5.2.2.2 Conference notification service 

In case of the subscription of a conference participant to the conference notification service, procedures according to 
3GPP TS 24.147 [7], subclause 5.3.3 shall apply. 

4.5.2.3 Void 

4.5.2.4 Void 

4.5.2.5 Void 

4.5.2.6 Void 

4.5.2.7 Actions at the destination UE 

Upon receipt of an INVITE request that includes a Replaces header, the UE shall apply the procedures described in 
RFC 3891 [8] to the INVITE request. 

4.5.2.8 Void 

4.5.2.9 Void 

4.6 Interaction with other services 

4.6.1 Communication HOLD (HOLD) 

The AS supporting the CONE service shall support the procedures for the held UE as specified in 3GPP TS 24.610 [12] 

4.6.2 Terminating Identification Presentation (TIP) 

No impact, i.e. neither service shall affect the operation of the other service. 
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4.6.3 Terminating Identification Restriction (TIR) 

For the conferencing AS implementing the conference focus, the following applies: 

If a participant is added to the conference and if TIR is active for the terminating party of this session, then the 
identity information of that participant shall not be included in conference notifications to other participants. 

4.6.4 Originating Identification Presentation (OIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.5 Originating Identification Restriction (OIR) 

For the conferencing AS implementing the conference focus, the following applies: 

If a participant joins the conference and if OIR is active for the originating party of this session, then the identity 
information of that participant shall not be included in conference notifications to other participants. 

If a REFER request is received and if the Privacy header field is set to "header" or "user", then for the INVITE 
request to the refer-to target, the conference AS shall: 

a) not insert the Referred-by header field, if it does not exist in the REFER request; or 

b) remove the Referred-By header field, if the Privacy header field of the REFER request is set to "user". 

If an INVITE request with "recipient-list" body is received, and if the Privacy header field is set to "user", then 
the conference AS shall anonymize the From header field of resulting relNVITE request, if there is established 
dialog between the conference controller and the target of the relNVITE request. 

4.6.6 CONFerence calling (CONF) 

Not applicable. 

NOTE: Cascading conference services are out of scope of the present specification. 

4.6.7 Communication Diversion services (CDIV) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.8 Malicious Communication IDentification (MCID) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.9 Anonymous Communication Rejection and Communication Barring 
(ACR/CB) 

The focus AS shall not accept REFER requests with a refer-to target that is barred by the conference creators 
Outgoing Communication Barring (OCB) rules. 

The focus AS shall remove the URI that is barred by the conference creator Outgoing Communication Barring (OCB) 
rules from the list of URIs in the "recipient-list" body of INVITE request. 

4.6.1 Explicit Communication Transfer (ECT) 

No impact, i.e. neither service shall affect the operation of the other service. 
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4.7 Interworking with other networks 

4.7.1 Void 

4.7.2 Void 

4.7.3 Void 

4.8 Parameter values (timers) 

Not applicable. 
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Annex A (informative): 
Signalling flows 

A.O Scope of signalling flows 

This annex gives examples of signalling flows related to the Conference (CONF) service. 

These signalling flows are simplified in that they do not show the AS to MRFC interactions nor the AS and MRPC 
functional split. 

A.1 CONF interworking signalling flow in case of an 
active communication between IMS and PSTN 

Figure A.l depictures a flow where two UEs are engaged in a call, and one of the users is located in the PSTN. At some 
point in time, UE A decides to activate the CONF service and move the call to a centralized conference. UE A creates 
the conference, and provides instructions to the conference server to contact UE B and replace the initial 
communication with a communication to the conference server. 
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Figure A.1 : CONF interworking signalling flow in case of an active communication 

between IMS and PSTN 

Description figure A. 1 

NOTE: Only the most relevant messages are shown in figure A. 1 

UE-A is in an active voice session with a PSTN/ISDN TE (SIP dialog with Call-ID, to-tag and fi^om-tag between UE-A 
and MGCF). It then creates a conference and invites the PSTN/ISDN TE to the conference by sending a REFER to the 
conference focus, which invites the PSTN/ISDN TE to the conference by sending an INVITE which includes the 
Replaces header to the MGCF. The MGCF confirms the session, switches the existing bearer channel to the new RTP 
session, and terminates the session which is replaced. 

1. to 3. UE-A initiates a voice session with a PSTN/ISDN TE by sending an INVITE request to the MGCF. 
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Table A.1 : 1. INVITE (UE-A to P-CSCF) 

INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 
To: <tel:+l-212-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port-c=8642 ; 
port-s=7531 

Contact : <sip : userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91eGbf 6 ;comp=sigcomp>; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept : application/sdp, . application/3gpp-ims+xml 

Accept -Contact : * ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
P- Preferred- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 99a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 3456 RTP/AVP 97 96a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 

4: Interaction to reserve resources. 

5: SS7: lAM. 

7: SS7: /^M. 

8: Interaction for session establishment. 

9 to 11: The MGCF sends a final response back to the session originator. 

Table A.2: 9. 200 OK (MGCF to S-CSCF) 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP bgcfl.homel.net;branch=z9hG4bK6546q2 .1, SIP/2. 0/UDP 

scscfl. homel. net ;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP pcscf 1 .homel .net ;branch=z9hG4bK4 31h2 3 .1, 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .homel .net; lr> 

P-Asserted- Identity: <tel : +1-212 -555 -2222 > 

P-Charging-Vector : 
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Privacy: none 

From: 

To: <tel: +1-212 -555 -2222 >;tag=314159 

Call-ID: 

CSeq: 

Require: 10 Orel, precondition 

Contact : <sip :mgcf 1 .homel .net ;gr> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

RSeq: 9021 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933623 2987933623 IN IP6 5555 : : eee : f f f : aaa :bbb 

s = - 

c=IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video RTP/AVP 98 99 

m=audio 6544 RTP/AVPF 97 96a=acfg:l t=l 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



12 to 14: The Calling party acknowledges the final response with an ACK request. 

15 to 24: UE-A creates a conference by sending an INVITE request to the Conference Factory URI and connects to the 
conference. 



Table A.3: 15. INVITE request (UE-A to P-CSCF) 



INVITE sip : conference- factorylOmrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net ; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171829 
To : <sip : conference- factorylOmrfcl .homel .net> 
Call -ID: Cb03a0s09a2sdfglkj 490444 
Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port-c=8642; 
port-s=7531 

Contact : <sip : userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf6 ;comp=sigcomp>; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Accept : application/sdp, . application/3gpp-ims+xml 

Accept -Contact : * ;+g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 
P- Preferred- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Content-Type: application/sdp 
Content-Length: (...) 



v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 99a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 
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a=rtpmap:98 H2S3 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVP 97 96a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



25 to 27: UE-A invites the PSTN/ISDN TE to the conference by sending a REFER request to the conference focus, the 
"method" parameter set to "INVITE". The Refer-To header of the REFER request includes the Replaces parameter with 
Call-ID, to-tag and from-tag from the existing SIP dialog. 



Table A.4: 25. REFER request (UE-A to P-CSCF) 



REFER sip: conferencel@mrfcl.homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip : origOscscf 1 .homel .net; lr> 
P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip : userl_publicl®homel . net> ; tag=171829 
To : <sip : conf erencelOmrf cl . homel . net> 
Call-ID: Cb0 3a0s0 9a2sdfglkj4 90555 
Cseq: 127 REFER 
Require: sec -agree 

Refer-To: <sip:mgcf 1 .homel.net; method=INVITE?Replaces=cb03a0s09a2sdfglkj490333%3Bto- 
tag%3D31415 9%3Bfrom-tag%3D17182 8S;Requrie=replaces > 
Referred- By : <sip :userl_publicl@homel .net> 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port- 
port-s=7531 

Contact : <sip : userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf6 ;comp=sigcomp>; +g. 3gpp . icsi_ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Content-Length: 



c=8642; 



27a: Interactions to reserve resources for an additional participant in the conference. 

28 to 30: The conference focus sends a NOTIFY request containing information about the progress of the REFER 
request processing. The Subscription-State is set to "active". 

31 to 32: The conference focus invites the PSTN/ISDN TE by sending an INVITE request to the MGCF. The INVITE 
request includes the Replaces header with Call-ID, to-tag and from-tag from the existing SIP dialog. 

Table A.5: 31. INVITE request (MRFC/AS to S-CSCF) 



orig-ioi=homel .net 



INVITE sip:mgcfl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP mrfcl . homel . net ;branch=z9hG4bK23273846 

Max-Forwards: 70 

P-Asserted- Identity : <sip : conf erencelOmrf cl .homel .net> 

P- Charging- Vector : icid-value = "AyretyU0dm+6O2IrT5tAFrbHLso=023551024'' 

Privacy: none 

From: <sip : conf erencelOmrf cl .homel .net>; tag=17112 3 

To: < sip :mgcfl .homel .net > 

Call -ID: bc03aOs09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: replaces 

Replaces : Cb03a0s09a2sdfglkj 490333 ; to- tag=314159; from- tag=171828 

Supported: precondition, lOOrel 

Referred- By : <sip :userl_publiclOhomel .net> 

Contact : <sip : conf erencelOmrf cl . homel . net> ; isf ocus 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 

Allow-Events : conference 

Content-Type: application/sdp 

Content-Length: (...) 
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v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : abc : def : abc : abc 

s = - 

c=IN IP6 5555 : :abc:def :abc:def 

t = 

m=video 10001 RTP/AVP 98 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 6544 RTP/AVP 97 96a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 

33: Interaction for switching existing bearer channel to new RTP. 

34 to 35: The MGCF sends a final response back to the session originator. 

35a: Interaction to add the participant to the conference. 

36 to 37: The Calling party acknowledges the final response with an ACK request. 

38 to 40: The conference focus sends a NOTIFY request containing information about the progress of the REFER 
request processing. The Subscription-State is set to "terminated". 

41: The MGCF replaces the existing RTP stream to UE-A with the new RTP stream to the conferencefocus. 

42 to 44: The MGCF releases the session with UE-A by sending a BYE request to UE-A. 

45 to 47: UE-A responds with a 200 OK response. 
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A.2 Call flow for 3PTYC0NF 

A.2.1 Invite other user to 3PTY CONF by sending REFER request 

Figure A.2 depictures a flow where two UEs, UE-1 and UE-2, are engaged in a call. At some point in time, UE-1 
decides to involve UE-3 into the communication and activate the 3PTY CONF service. UE-1 puts UE-2 on hold, 
initiates a session toward UE-3 to get the user's permission to start 3PTY call, creates the conference, and moves the 
original communication with both UE-2 and UE-3 to the conference server. 
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UE-1 



P-CSCF 



S-CSCF 



AS/MRFC 



UE-2 



MRFP 

I 



1. UE-1 and UE-2 is in a multimedia session 



-Media Path to UE-2- 



-►J 



2. UE-1 Puts UE-2 on hold 



3. INVITE(UE-3) 



8. 200 OK (INVITE) 



12. INVITE (CS) 



18. 200 OK (INVITE) 



22. REFER(UE-2)wRefer- 



_27^202Accepted_ 



.30. NOTIFY (lOOTrying) 



31. 200 OK (NOTIFY) 



43 NOTIFY (200 OK) 



44. 200 OK (NOTIFY) 



52 200 OK (BYE) 



53. REFER(UE-3)wRefer- 
To:CS 1 



58. 202Acoepted 



61. NOTIFY (100 Trying) 



62. 200 OK (NOTIFY) 



74 NOTIFY (200 OK) 



75. 200 OK (NOTIFY) 



83 200 OK (BYE) 



4. INVITE(UE-3) 



7. 200 OK (INVITE) 



13. INVITE (CS) 



17. 200 OK (INVITE) 



-Media Path to UE-3- 



14. INVITE (CS) 



5. INVITE(UE^) 



I. 200 OK (INVITE) 



11.ACK 



1 5. Interaction for creating 
Conference 



16. 200 OK (INVITE) 



— Media Path betweeh UE-1 
23. REFER(UE-2) w Refer- 



26. 202 Accepted 



.29. NOTIFY (100 Trying) 



32. 200 OK (NOTIFY) 



42. NOTIFY (200 OK) 



45. 200 OK (NOTIFY) 



51. 200 OK (BYE) 



54. REFER(UE-3)wRefer- 
To:CS 1 



57. 202 Accepted 



60. NOTIFY (100 Trying) 



63. 200 OK (NOTIFY) 



73. NOTIFY (200 OK) 



76. 200 OK (NOTIFY) 



82. 200 OK (BYE) 



24. REFER(U 



28 NdTIFY (IOC Trying) 



DO OK (NC TIFY) 



36. Interaction for resource 
for an additional participant 



37. 200 OK (INVITE)- 



38. 200 OK (INVITE) 



41.rOTIFY(2[0OK) 



46. 



DO OK (NC TIFY) 



50. 200 OK (BYE) 



-Media to UE-2- 



REFER(UE-3)w Refer-To: 



56. 202 Accepted 



59. NOTIFY (lOOTrying) I 



64 200 OK (NOTIFY) 



65 INVITE 



67. Interaction for resource 
for an additional participant 



63. 200 OK (INVITE) 



I. 200 OK (INVITE) 



70. ACK 



72. NOTIFY (200 OK) 



77. 200 OK (NOTIFY) 



81. 200 OK (BYE) 



UE-3 



Media to UE-3- 



Figure A.2: Call flow for 3PTY conference 

UE-1 and UE-2 are in an active call. UE-1 decides to add UE-3 to make it a 3-way conferencing call. 
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1. UE-1 and UE-2 are in an active call. 

2. UE-1 puts UE-2 on hold before invoking the 3-Way Calling with UE-3. 

3-11. UE-1 establishes a call with UE-3 following normal call setup procedure and gets UE-3"s permission to start the 
3 -Way Calling. 

12-14. UE-1 sends an INVITE request to the conference server to establish a conference session. 

15. The CS coordinates with MRFP to allocate conference resources. 

16-21. The CS sends a 200 (OK) response and receives an ACK request from UE-1. 

22-27. UE-1 sends a REFER request to UE-2 with the Refer-To header set to the address of the CS; UE-2 accepts the 
REFER request. 

28-33. UE-2 sends a NOTIFY request to UE-1 to indicate that UE-2 is acting on the REFER request. 

34-35. UE-2 sends an INVITE request to the CS to join the conference. 

36. The CS coordinates with MRFP to allocate more resources. 

37-40. The CS sends a 200 (OK) response to UE-2 and receives an ACK request. 

41-46. UE-2 sends a NOTIFY request to UE-1 to indicate that it has finished action required by the REFER request. 

47-52. UE-1 sends a BYE request to terminate the call between itself and UE-2. 

53-58. In parallel to step 22-52, UE-1 sends a REFER request to UE-3 with the Refer-To header set to the address of 
the CS; UE-3 accepts the REFER request. 

59-64. UE-3 sends a NOTIFY request to UE-1 to indicate that UE-3 is acting on the REFER request. 

65-66. UE-3 sends an INVITE request to the CS to join the conference. 

67. The CS coordinates with MRFP to allocate more resources. 

68-71. The CS sends a 200 (OK) response to UE-3 and receives an ACK request. 

72-77. UE-3 sends a NOTIFY request to UE-1 to indicate that it has finished action required by the REFER request. 

78-83. UE-1 sends a BYE request to terminate the call between itself and UE-3. 

A.2.2 Invite other user to 3PTY CONF by sending INVITE request 
with URI list 

Figure A. 3 depictures a flow where UA-A is involved in 2 communications with UA-B and UA-C, both 
2 communications are on-hold. The AS is involved in both 2 communications as a B2BUA. 

When user A intends to start the 3PTY conference, UA-A sends an INVITE request to the AS to create the conference 
and indicates that certain dialogs will be re-used for this conference. The AS sends re-INVITEs in the indicated dialogs 
and connects the media to the conference bridge. The dialogs can be indicated by adding the Call-ID header field, the 
From header field and the To header field to the entries in the URI list of the initial INVITE request. 
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UA-A 



AS/MRFC 



■-Call-ID la, on-hold-- 
"Call-ID 2a, on-hold-- 



INVITE CONF AS 

To: CONF AS 

From: A _ 

Call-ID: 3a 

Require: recipient-list-lnvite 



-200 OK- 
— ACK— 



■■Call-IDIa, on-hold" 
"Call-ID 2a, on-hold" 
—Call-ID 3a, active- 



-Media stream 3a- 



MRFP 



UA-B 



•■Call-ID1b,on-hold-- 



UA-C 



-Call-ID 2b, on-hold- 



INVITE CONF AS 

To: CONF AS 

From: A 

Require: recipient-list-invite 

Content-Type: application/resource-lists+xml 
Content-Disposition: recipient-list 

<?xml version="1 .0" encoding="UTF-8"?> 
<resource-listsxmlns="urn:ietf:params:xml:ns:resource-lists" 

xmlns:cp="urn:ietf:params:xml:ns:copyControl" 

<list> 

<entry uri="B?Call-l D=1 a&From=A&To=B?cp:copyControl="to"/> 

<entry uri="C?Call-l D=2a&From=A&To=C?cp:copyControl="to"/> 

</list> 
</resource-lists> 



re-INVITE B 
To:B 
From: A 
-Call-ID: 1b - 

a=sendrecv 
o=l\/lRFP 



-200 OK- 
— ACK— 



re-INVITE C 
To:C 
From: A 
-Call-ID: 2b - 

a=sendrecv 
o=l\/IRFP 
I 
200 OK — 

ACK 



"Call-ID1b, active- 



-Call-ID2b, actiue-- 



-Media stream 1 b- 



-Media stream 2b- 



Figure A.3: Call flow for 3PTY conference 

1 : UA-A creates a conference and invites user B and user C to the conference by sending an INVITE request to the 
Conference Factory URI and including URI Hst in the INVITE request, UA-A indicates the certain dialogs which be re- 
used for this conference in the uri list by ? mechanism. 

INVITE CONF AS 

To: CONF AS 

From : A 

Require: recipient-list-invite 

Content-Type : application/resource-lists+xml 
Content -Disposition: recipient -list 

<?xml version="l . 0" encoding="UTF-8" ?> 
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<resource- lists xmlns="urn: ietf iparams :xml :ns : resource- lists" 
xmlns : cp="urn: ietf iparams :xml :ns : copyControl" > 
<list> 
<entry uri="B?Call-ID=la&From=A%3Btag%3Da&To=B%3Btag%3Db" cp : copyControl="to"/> 
<entry uri="C?Call-ID=2a&From=A%3Btag%3Da&To=C%3Btag%3Dc" cp : copyControl="to"/> 
</list> 
< /resource- list s> 

2: AS verifies if the dialogs in URI list matches to a partial dialog which AS already involved, In the case of a match the 
AS use this dialog ID information to send re-INVITE request to UA-B and UA-C in the partial dialogs between the AS 
and the invited users in order to connect the media of the invited users to the MRFP. 



A.3 CONF call with REFER interworking at the AS 

Figure A.4 depicts a flow where two UEs, UE-1 and UE-2, are engaged in a call. At some point in time, UE-1 decides 
to involve UE-3 into the communication and activate the CONF service. In this scenario, third party call control at the 
AS is employed to interwork the REFER request to an INVITE request. Such a scenario is applicable since some 
endpoints do not support the REFER method. 
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52. UE-1 uses similar procedures as 1 7~50 to add UE-3 to conference and drop the old call. 



-Media to UE^3- 
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Figure A.4: CONF call with REFER interworking at the AS 



UE-1 and UE-2 are in an active call. UE-1 decides to add UE-3 to make it a 3-way conferencing call. 

1: UE-1 and UE-2 are in an active call. The AS is put on the signalling path of this call by invoking the iFC. The 
dialog ID between the AS and UE-2 is Dl. 

2: UE-1 puts UE-2 on hold before invoking the 3-Way Calling with UE-3. 

3: UE-1 establishes a call with UE-3 following normal call setup procedure and gets UE-3"s permission to start the 
3-Way Calling. The AS is put on the signalling path of this call by invoking the iFC. 
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4: UE-1 decides to covert the two on-going calls into a 3-way call and puts UE-3 on hold. 

5 to 8: UE-1 sends an INVITE request to the CS to establish a conference session. The AS is put on the signalling 
path of this call be invoking the iFC. The dialog ID between the AS and the CS is D3. 

9: The CS coordinates with MRFP to allocate conference resources. 

10 to 17: The CS sends a 200 (OK) response and receives an ACK request from UE-1. 

18 to 23: UE-1 sends a REFER request to UE-2 with the Refer-To header set to the address of the CS. The AS 
sends a 202 (Accepted) response and terminates the REFER request in order to perform REFER interworking. 

24 to 29: The AS sends a NOTIFY request to UE-1 to indicate that the AS is processing the REFER request. 

30: The AS sends an empty INVITE request to the CS (dialog D4) to join the conference created by UE-1. 

31: The CS coordinates with MRFP to allocate more resources. 

32: The CS sends a 200 (OK) response to the AS. This response includes an SDP offer (Ol) based on the conference 
information. 

33 to 34: The AS sends a re-INVITE request with SDP offer (Ol) to UE-2 on the existing dialog (Dl) to update the 
session to conference session. 

35 to 36: UE-2 sends a 200 (OK) response to the AS to acknowledge the re-INVITE request. This response 
contains an SDP answer (Al) based on the SDP offer (Ol) received. 

37: The AS sends an ACK request with SDP answer (Al) to the CS to reply to the SDP offer received in Step 32. 
End-to-End offer/answer exchange between the CS and UE-2 is completed. 

38 to 39: The AS also sends an ACK request to UE-2 to acknowledge the 200 (OK) response from UE-2. 

40 to 45: The AS sends a NOTIFY request to UE-1 to indicate that it has finished action required by the REFER 
request. 

46 to 51: UE-1 sends a BYE request to terminate the dialog used for communication between itself and UE-2. 

52: In parallel to step 18 through 51, UE-1 follows the similar procedures to add UE-3 into the conference. 
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